The present invention relates to a method of preventing cross-site request forgery (CSRF) and, more specifically, to a method of CSRF prevention that can be implemented at a server level.
CSRF is a type of an attack that tricks a victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For most sites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim.
CSRF attacks target functionality that causes a state change on the server, such as changing the victim's email address or password, or purchasing something. Forcing the victim to retrieve data doesn't benefit an attacker because the attacker doesn't receive the response, the victim does. As such, CSRF attacks target state-changing requests. It is sometimes possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called “stored CSRF flaws.” This can be accomplished by simply storing a tag in a field that accepts HTML or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood of the attack occurring is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is probably authenticated to the site already.
Current solutions for CSRF prevention include white-listing and the use of CSRF tokens. In white-listing solutions, existing applications create registries of accepted domains (i.e. HTTP referrers) that are allowed for a given application and then check the HTTP_REFERER and HTTP_ORIGIN fields (if any such fields exist) against those registries. The application thus needs to repeatedly manage and check the registries or permit external management using security profiles. This requires creating a new class of security profiles and authorities that are separate from the client certificates that are already being used to implement user authentication.
In the CSRF token approach, the application generates a token and passes it back to the client upon authentication. Subsequently, the client needs to pass in the token on each transaction with the server application needing to be modified to provide or accept the CSRF token and the client application needing to be modified to use the token. Unlike a cookie, the token would not be cached in the browser and there may be additional overheard required by the server and client applications. The CSRF token approach can also be defeated by attacks that submit requests twice.